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EXCOM 81-9032 


17 July 1981 


MEMORANDUM FOR: Executive Committee Members 

FROM : Director, DCI/DDCI Executive Staff 

SUBJECT : Executive Committee Review of Information 

Systems Architect Mission and Functions 


1. The Executive Committee will meet on Friday, 24 July, at 10:00 AM in 
the DCI Conference Room to review the mission and functions of the Information 
Handling- Systems Architect (THSA). The EXCOM agreed last fall to have such a 
review once the new Architect had had time to get settled and evaluate Agency 
information handling. 


will begin the session with his evaluation and 
7 his written report is at Attachment A. 

3. You should be prepared to give the DDCI your views on the following: 

(a) Approval of the Appendix B plan and procedures for the two- 
year development of a CIA information handling systems 
strategic plan. 

(b) Approval of Appendix C policy and procedures with special 
attention to systems approval processes and paragraph five 
IHSA responsibilities.' 

(c) Approval of Appendix D as the charter for the IHSA, replacing 
all previous notices and charters, giving special attention 
to those functions concerning IHSA approval authority (2c), 
development and promulgation of standards (2k), and coordi- 
nation of information handling systems training (2m). 


2. IHSA 
recommendatioi 



Hand! ing 
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REPORT OF THE IHSA TO THE EXCOM, JULY 1981 

1 . Background 

In the winter of 1979 the EXCOM commissioned a study of 
information handling in the Agency. A task force of five members 
was assembled, broadly representing the Agency operational 
interests. They also gave breadth to technological considerations 
through the diversity of their backgrounds. The study took one 
year, and involved extensive interaction with much of the senior 
management of the Agency. The final report of the Information 
Handling Task Force (IHTF) was published this spring. (Reference A) 

The study team was charged to investigate: the management 
of information handling systems, standards governing their 
development and acquisition, implementation management, organi- 
zation of the Agency for effective utilization of IHS, and the 
strategy for effective utilization of compartmented information. 

The recommendations made in the final report following the year 
long study effort addressed organizational and management changes, 
programmatic objectives, security procedures, personnel manage- 
ment, and policy. 

Perhaps the primary recommendations of the Task Force was 
the establishment of the office of Information Handling Systems 
Architect (IHSA), with the mission of performing Agency-level 
planning for information services with particular emphasis on 
applying advanced technology. The missions and functions of 
the IHSA were discussed in several meetings of the EXCOM and 
resulted in the missions and functions statement forwarded by 
the DDA to the EXCOM (reference B) and Attachment 2 thereof 
(Appendix A) . The functions in this statement were broadly 
defined, presumably with the understanding that recommendations 
with repect to implementing procedures would be developed by 
the IHSA. One of the principal objectives of this presentation 
is to put forward the procedures by which the IHSA believes 
these functions are best implemented. It is the additional 
purpose of this briefing to brief the EXCOM on the organization 
and status of the IHSA and its accomplishments to date. 

2 . Staffing 


The IHSA was selected in the fall of 1980 and entered on 
duty January 5, 1981. After a brief period of familiarization, 
the professional skills required of the remaining four staff 
members were determined, job descriptions for these positions 
prepared, vetted, and forwarded to the Office of Personnel for 
authorization. Searches were then made against these job 
descriptions, beginning with the Deputy of the Office. 

All four staff officers have now been selected. They 
provide the office with expertise in systems management, systems 
software, systems hardware, communications, and analysis and 
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evaluation of systems performance. They all come from within 
the Agency, and provide a broad familiarity with Agency systems 
and procedures. The officers of the staff are: 


* | | (SIS- 2) - former technical 

director of the Consolidated SAFE Project Office; 
four years in the Agency; strong industrial background 
in hardware and software aspects of systems development. 


* | J (GS- 1 5) - former senior communications 

officer in the OSO; a senior career communications 
officer with overseas station management and network 
development experience. 

* | ~1 (GS-14) - former section leader 

in the CAMS Management Branch, PTO; career Agency 
employee with experience in management procedures for 
the acquisition of large information handling systems; 
a principal participant in the development and acquisi- 
tion of the Agency's standard GIMS data base management 
system. 


| C GS - 1 3 ) - former analyst with 

IMS in the DDO; responsible for the recent development 
of IMS' strategic plan for information handling systems 
into the 1990's; contributed widely to the development 
of the NDS at the NPIC. 

Although not expressed as a recommendation of the IHTF, 
it was felt that the office of IHSA could be of the greatest 
value to the Agency if staff members could be assigned on a 
rotational basis. This would permit them to gain experience in 
the planning and management of the development of integrated 
Agency information handling systems from the perspective of such 
an office. They could then carry that knowledge back with them 
to specific developmental responsibilities in the operational 
components. For that reason, all the selected staff members 
are on rotational assignment to this office. 

3 . Progress to Date 


(1) Familiarization 


Guiding the efforts relevant to staffing and 
planning the initial efforts of the office has been 
the early familiarization of the Architect with the 
various offices and projects of the Agency. The IMS 
involvements of the Agency are so broad, that even 
at this point the knowledge of the Architect is sub- 
stantially incomplete. Nevertheless, it is felt that 
most of the principal thrusts and developmental concerns 
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that are going to be important to the Agency IHS 
architecture are understood and appreciated. With 
the recent addition of the remaining staff members, 
it will now be possible for the office to become 
familiar with some of the broader scoped and more 
complex developments. To date the familiarization 
has primarily encompassed the relevant offices of 
the DDA, IMS in the DDO, and NFAC. 

(2) Documentation of the Current Architecture 


Fundamental to developing any long range plan 
for Information Handling Systems in the Agency is 
a clear understanding of where we are today. Toward 
that end, two studies have been contracted for to 
define elements of the current system architecture. 

In both of these instances, it was found that there 
were other studies beginning for which the required 
data collection was nearly identical to system 
definition needs of this office. As a consequence, 
the system documentation efforts were developed as 
amendments to these new study contracts. Essentially, 
they require that the contractors document the data 
they collect on the current systems for the purpose 
of designing new capabilities. 

One of these systems documentation efforts is 
the documentation of major data bases within the 
Agency and their data flow interrelationships. The 
focus is on the larger and broadly used data bases, 
since by their size and and importance, they tend 
to become the "rocks" to which the future architec- 
tural developments must be accommodated. The product 
of this effort is to be a reference document defining 
the Agency's current "data base architecture”. 

The second effort is to document the Washington 
area external communications network. It is "piggy 
backing" a contractor study developing and evaluating 
design alternatives for this network. The product 
is a reference document defining this external 
communications network. 

The prototype for such sectional documentation 
of the current architecture is the documentation 
of the Headquarters Building data traffic flow 
(reference C) . This document was originally 
produced about two years ago by the Office of Data 
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Processing, and defined the network linking the 
major functionalities in the Headquarters Building. 

As part of the current systems documentation effort, 
this study will be updated by the ODP to reflect 
the current status. This particular effort is 
smaller than the other two and will be done internally. 

(3) Development of Standards 

As a result of the establishment of the IHSA, 
it now chairs the Standards Committee. This 
committee, commissioned in 1979 by the DDCI, is 
charged with developing Agency-wide professional 
standards for systems development requirements, 
requirements definitions, specifications, and 
documentation. 

It became clear in reviewing the effort avail- 
able to the committee from its members that in order 
to achieve the desired rate of progress, contractor 
support would be required. An effort is now under 
way to acquire such support. When it is available, 
the committee will then function as a review, modi- 
fication and approval body, working with the draft 
standards developed by the contractor. The members 
will function both on the basis of their individual 
expertise and as representatives of their components. 

(4) Interaction with New Systems Developments 


In the process of becoming familiar with the 
Agency programs, the IHSA has interacted with 
various major systems developments. Included 
were SAFE, CRAFT, terminals, and scientific 
programming and computational requirements. The 
interaction has been in the context of the relation- 
ship of such systems to the overall Agency IHS 
architecture . 

(5) IHS Acquisition Review 


As a checkpoint in assuring that Agency IHS 
acquisitions are consistent with the integrated 
architectural objectives of the Agency, the IHSA 
has become formally involved in the contract review 
process. The IHSA has been designated as an Advisor 
to the Agency Contract Review Board on all procure- 
ment actions involving information handling systems. 

In addition he will review all Requests for Procure- 
ment Services (Form 2420) and Request for Procurement 
Action memoranda for IHSs for Class I and Class II system 
acquisitions (see Appendix C for definitions) . 
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(6) IHS Training Within the Agency 

Because of a concern developed by the System 
Architect in his familiarization with IHSs in the 
Agency, a preliminary study by 0T§E of the IHS 
training requirements was requested. This study 
has just been completed. It indicates that we 
have a training demand which substantially exceeds 
our current resources, and that, as an Agency, we 
have not begun to do the necessary planning and 
budgeting to deal with it. 

4 . Major Thrusts of the IHSA 

The activities of the IHSA can be aggregated into 
three areas: 

* Strategic Planning 

* Current Programs Interaction 

* Environment Development 

It is the judgement of the IHSA that the first two categories 
have a symbiotic relationship. Without the other, efforts in 
either area are of little value. A background strategic plan- 
ning effort is required to provide the long term perspective 
needed in assessing the architectural implication and require- 
ments of current programs. Concomitantly, to be of value, 
strategic planning has to be firmly based on the character- 
istics of existing and developmental systems. Any system now 
under development can be expected to have a useful life on the 
order of ten years, and this exceeds the technological horizon 
in today's fast moving information systems environment. As a 
consequence, what is being developed now, to a significant 
extent, will define the future. A consequence is that strategic 
planning without current program interaction is merely an 
academic exercise. 

The environment development activities encompass such 
elements as standards, training, the software development 
environment, computer aided instruction, and the "user friendli- 
ness" of systems. As the Agency now moves forward to develop 
needed systems and subsystems of major size, it is recognized 
that we need to develop a common culture with respect to IHSs . 

We simply cannot rely upon standards to achieve commonality 
with respect to procedures, design techniques, and documentation. 
And without commonality amongst these factors, achieving an 
interoperable and unified architecture is judged to be very 
difficult, if not impossible. Thus the IHSA associates 
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great importance with the Environment Development activity 
in achieving the Agency's objectives with respect to the 
development of an integrated IHS Architecture. 

5 . Implementation of the Charter 

The missions and functions of the IHSA appear in a variety 
of sources, principally the Information Handling Task Force 
report and the DDA memorandum for the EXCOM summarizing the 
committee's findings. The latter enclosed the action recom- 
mendations and the revised mission and function statement 
for the Architect of Information Services (now IHSA) . The 
succinct character of the statements of missions and functions 
in these documents puts the burden on the IHSA to define their 
proposed implementation. In this section, this implementation 
is discussed in terms of six functions which map into the 
three areas of activities previously discussed: 

* Information collection 

* Strategic planning 

* Implementation and support of the IHS 

management process 

* Accreditation of requirements for architectural 

components 

* Coordination of IHS training 

* Development and promulgation of Agency standards 
(1) Information Collection 


The first requirement for the IHSA to be able 
to perform its mission is the collection of infor- 
mation relevant to the development, acquisition, 
enhancement, maintenance and operation of information 
handling systems in the Agency. Without a thorough 
knowledge of where we are today and what we are 
building and acquiring, effective strategic planning 
is impossible. 

The information collection requirements of the 
IHSA are implied by function number 1 of Appendix A 
and specifically addressed in functions 2, 6, 7 and 
10 . 
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In order to support interaction with current 
programs, the types of data needed include: 

* Functional requirements 

* Program acquisition plan 

* Feasibility analyses and trade-off studies 

* System specification 

* Management Plan 

* System functional specifications 

* Interface control specifications 

* System detail design specifications 

* System test and validation plan 

Such documents should be supplied to the IHSA 
as they become available within the process of system 
acquisition. Other documents relating to operation 
of the system should only be provided on request, 
because their availability is not routinely relevant 

to the functions of the office. 

« 

Additional support may be needed from the various 
Offices performing IHS functions relevant to defining 
the current architecture. While the three studies 
mentioned earlier will provide a substantial definition 
of the existing architecture, they do not present the complet 
picture. As further areas of the existing architecture 
which are not documented are demarcated and funds 
become available, commissions for development of such 
documentation will be made by the IHSA. 

(2) Strategic Planning 

The development of a strategic plan for the Agency's 
IHSs will of necessity involve all of the IHS service 
and user organizations, as well as the IHSA. It is 
a job which will require approximately two years effort, 
and be a continuous background activity to the other 
functions. Recognizing that, as discussed earlier, 
strategic planning is a concomitant activity to inter- 
action with current development programs, strategic 
planning is probably the most important function of 
the IHSA. 
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In order to function effectively, it will be 
necessary for the IHSA to call upon the various IHS 
service Offices for support in developing portions of 
the strategic plan. The IHSA is too small to develop 
all of the detail required in a comprehensive 
strategic plan, and should "not attempt to do so under 
any circumstances. Rather, the office should 
commission strategic plans in subsection areas within 
the purviews of various specific offices, as needed 
to support the overall planning process. This is 
the classic format of strategic planning in large, 
private organizations: a small planning staff sets 
and defines objectives and then requests line organi- 
zations to develop detailed plans supporting those 
ob j ectives . 

The process is an iterative one, with the planning 
staff reacting to the component plans. Typical re- 
active questions are those concerning interfaces, 
architectural alternatives and technology inclusion. 

The component organizations may then be asked to recycle 
the plans to respond to these broader considerations. 

The IHSA will focus most of its attention on matters 
pertaining to interfacing systems and network performance. 

It should be recognized, however, that there may 
be specific technical questions in particular areas 
which will receive the concentrated attention of the 
office. But, to attempt to do such on a broad basis, 
would be for the IHSA to intrude excessively into the 
operational planning responsibilities of line organi- 
zations. Thus, the commissioning process is a necessary 
part of the strategic plan development. 

The overall plan for the development of a strategic 
plan, at this point in time, is composed of three parts. 
The first is the development of a rough draft strategic 
plan encompassing the entire IHS architecture of the 
Agency. The intent of this draft is to cover as 
completely as possible all of the elements, providing 
the various components with planning material to which 
they can react. The IHSA will seek as much information 
as can be provided on an informal basis from service 
and user organizations, but will not institute a formal 
requirements definition effort. The latter is judged 
marginally more useful than the informal approach, and 
consumes considerably more time and resources. 

Completion of this first phase is estimated to be one 
year from initiation. 
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In the second phase, the responses of the 
various organizations will be accommodated into a 
unified draft plan. Working with the Comptroller 
this unified draft plan will also be brought into 
rough harmony with budgetary expectations and 
estimates. In order to do this, it may be necessary 
to vary the time phasing of the various programs 
so as to reconcile the gross demand of these programs 
upon the personnel and financial resources of the 
Agency, with their likely availability. It is 
anticipated that this phase should require about 
eight months. 

In the last phase of the development the final 
plan will be produced, taking into account the comments 
on the unified draft plan. This plan will include 
budget projections for the next four outyears. The 
plan itself, however, will extend for a period of 
about ten years. Clearly, there will have to be 
significant Comptroller and EXCOM involvement in this 
final phase to achieve the gross objectives of the 
Agency. This will be needed in sorting out the 
priorities with respect to resource allocation, and 
in determining the necessary levels of resource 
commitments. • 

The specifics of the implementation process for 
strategic plans are discussed in Appendix B. 

(3) Implementation and Support of the IHS Management 
x Process 


The proposed program for oversight management 
of the development of IHSs in the Agency is based 
upon the proposition that the appropriate oversight 
management level and process varies with the size of 
the system. The presumption is that the architectural 
impact and risks vary roughly in proportion to the 
size. Consequently, it is the recommendation of the 
IHSA that the systems be categorized for the purpose 
of oversight management based upon the size of the 
commitment involved. The largest systems are those 
requiring a substantial portion of the Agency's 
resources to effect, and thus represent a corporate 
commitment, even if totally serving a single user. 

An intermediate class would be those of significant 
size and importance with respect to the overall 
Agency IHS architecture, but not representing 
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significant commitments and risks to the Agencv 
as a whole. The smallest group of systems would 
be those which are generally resident upon large, 
general service systems, and which do not affect 
the architecture, other than to represent demands 
for service. 

It is recommended, then, that there be three 
categories of systems: Class I (Large), Class II 
(Medium) and Class III (Small). The thresholds 
defining the boundaries between these classes are 
acquisition cost values. It is recommended 
that the oversight management responsibility 
for the smaller two be delegated to the Directorates, 
and that the Directorates delegate that for the 
smallest to the constituent offices. An exception 
to such delegations may be systems with multiple 
user components. 

The recommended oversight-management review 
process consists of three milestones: the planning 
milestone, which is a budgetary milestone and which 
should interface with periodic budgetary processes; 
the systems specification milestone, which is a 
management milestone; and a preliminary design review 
milestone, which is a management milestone. The 
scheduling of the last two is determined by the 
characteristics of the project, and are not syn- 
chronized with any periodic process. This basic 
management review process would apply to all three 
categories of systems, and there should be documen- 
tation requirements for each milestone. 

A format for such a top management process for 
managing the development of systems is attached as 
Appendix C. It is recommended that the IHSA be 
authorized to develop a DCI directive concerning 
oversight management for the development of IHSs 
based upon this format. 


(4) Accreditation of Requirements for Architectural 
Components 

The development of requirements for a new 
system is normally the responsibility of the user. 
Interpreting this as an exclusive prerogative, 
however, has been a prime source of problems 
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within the EDP world. A pattern of exercising 
such a prerogative usually results in noninter- 
operable systems and projects which fail to meet 
their performance objectives within their defined 
cost and schedule envelope. 

Some of the principal problems deriving from 
identifying requirements as a user prerogative are: 

* Lack of a reconciliation of user's 
requirements with the implementation 
environment ; 

* Inadequate attention to adjunct user 
requirements; and 

* Lack of a consolidation and validation 
mechanism for requirements derived from 
a community of users. 

The lack of reconciliation involves an inter- 
active process between the user and the developer. 

The system requirements should evolve from the 
functional requirements as the consequence of an 
interplay between the techniques and mechanisms of 
their implementation and the restructuring of user 
organizations and operations in conjunction with 
the new system. One of the worst mistakes that can 
be made is simply to automate current manual procedures 
the result is usually a system several times the 
size and cost as is needed to satisfy the need. 
Implications of such a direct transformation approach 
are not always well understood by user organizations. 

With reference to adjunct user requirements, 
there is an increasing functional complexity of 
Agency systems due to the increasing involvement 
of adjunct users. We are now developing systems 
like LIMS, a Logistics system with many adjunct user 
organizations. The problem of the definition of the 
requirements for such a system can be difficult, 
particularly when an IOC date and funding constraints 
force compromises. 

Lastly, there is the problem of requirements 
for general services systems. The requirements 
for these systems drive their costs, availability, 
and acceptance just as they do for any other. 

The problem is the establishment of an acceptable 
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but not excessive set of requirements. There 
have to be compromises of both user needs and 
developer implementation preferences in order 
to achieve a cost effective result. In addition, 
to assure a system that fills an adequate 
serviceable life. and provides an effective inte- 
gration into the Agency IKS architecture, the acquisi- 
tion strategy should reflect, insofar as possible, 
the market availability of the desired technologies. 

All of these examples reflect a strong need 
for accreditation of a new systems functional 
requirements. For complex systems, this can 
only be done at an Agency-wide level, because the 
problem is an ecumenical one. It also requires 
concentrated top-level attention, because the 
problems are complex; however, these problems 
cannot be successfully dealt with in an EXCOM- c> 
type project review unless the key issues and 
tradeoffs have already been identified and 
analyzed . 

To effect this requirements oversight, the 
IHSA has been designated to receive all Requests 
for Procurement Services (Form 2420) and Requests 
for Procurement Action memoranda, for Class I 
and Class II information systems received by 
the Procurement Office of the Office of Logistics. 

If any problems are found with such requirements, 
the IHSA will deal directly with the originating 
component to resolve such problems. 

(5) Development and Promulgation of Standards 

Achieving a unified and interoperable 
architecture is impossible without a set of 
standards to guide the process of systems 
development. Through the common approach pro- 
vided by such standards, the myriad small details 
that affect systems technical and functional 
interoperability can be successfully resolved. 

We need standards in three areas relative 
to IHS development: 
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* Management procedures and development 
processes 

* Interface control 

* Data item specification (e.g., per CDRL) 

Examples of documents in each category exist in 
the Agency, some of them excellent. But we do 
not have anything approaching a complete set of 
such standards even in local environments. A 
moderate or large-sized systems development can 
readily require the adherence to or production of 
20 different documents. For the project personnel 
to figure all that out de novo is an unreasonable 
requirement, and it is certainly not going to 
produce an homogenous environment. We need a 
uniform set of Agency-wide standards to serve as 
a baseline for system developers. Providing a 
normative process and a complete documentation 
baseline is the objective, not rigid adherence to 
a set of overly detailed specifications and 
standards . 

In order to have a single set of such standards 
and have them for the entire Agency, we need 
centralized development and promulgation of standards. 
In recognition of this fact, the Office of Data 
Processing has recently transferred chairmanship 
of the Agency Standards Committee to the IHSA. 

This committee, chartered by the DDCI in 1979, has 
the commission of developing the Agency-wide 
standards that we need to support our investments 
in developing an integrated information handling 
system architecture in the Agency. 

(6) Coordination of Information Handling Systems 
Training 


STAT 


As mentioned earlier, the second dimension 
of developing a common IHS culture within the 
Agency is training. To develop a common culture, 
a common understanding in dealing with IHSs , we 
need to put a major emphasis on IHS training. 

To do the job it has to do, that training has to 
be centraliz ed. The engineer acquiring software 


for 


in OC should have the same approach 
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and require of the contractor the same procedures 
and documentation as that acquiring the CAMS in 
ODP , as that acquiring CRAFT in IMS. If they do 
not, the problem of making these systems interoperate 
is made immeasurably more difficult. 

There are two types of training required: skills 
and disciplinary. We have a comprehensive course 
structure for the former, generally dispersed through- 
out the Agency. Disciplinary, or prof essional - level , 
training, however, is generally handled on an ad hoc 
basis. We do not have a regular program in disciplinary 
skills such as that offered by the Information Science 
Center in 0T§E in analytic tools to the Intelligence 
Community. It is clear from the OTfjE study that there 
is a looming demand for a substantial increase in IHS 
training throughout the Agency. The resources required 
to support this training requirement clearly need 
to be increased, and the study indicates that this 
increase will be substantially less if done centrally 
than on a distributive basis.- Distributed IHS 
training presents a greater concern, however, of 
developing a common IHS culture within the Agency. 
Developing an IHS training program that will meet 
the needs of the Agency components, component -unique 
training excluded, will require top-level guidance 
and support, and should rely heavily on centralized 
resources . 
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APPENDIX A 

ARCHITECT OF INFORMATION SERVICES:* 


MISSION : 

Performs Agency level planning for Information Services with 
particular emphasis on application of technology. 


FUNCTIONS : 

1. Publishes Strategic goals and objectives for purpose of 
program guidance. 

2. Monitors progress toward goals and objectives and reports 
state of Information Handling to EXCOM (incorporates ADP 
review) . 

3. Provides final approval for all agency information handling 
systems architecture. 

4. Consolidates requirements for IH to maximize commonality and 
minimize unique development. 

5. Conducts design reviews during conceptual design phase. 

6. Maintains technology forecast and reports trends to 
management . 

7. Acts as Agency focal point to Community on matters of IH. 

8. Commissions system designs to fulfill architecture. 

9. Initiates studies and analyses for the purpose of identifying 
ways to improve effectiveness and efficiency of IH. 

10. Maintains a current data base on the status of information 
systems and their interrelationships. 


* Attachment 2 of Reference B 
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APPENDIX B 

INFORMATION HANDLING SYSTEMS 
STRATEGIC PLANNING 


1.0 GENERAL - SCOPE AND PURPOSE 


A Strategic Plan for Information Handling Systems shall 
be developed and maintained. The Plan shall be published 
annually in time to provide goals, objectives, and imple- 
mentation strategies to guide other Information Handling 
Systems planning, programming, and budgeting activities. 

The scope of the Strategic Plan is electronically-based 
systems which affect the creation, movement, use, storage, 
retrieval, and disposition of intelligence and management 
information. 

The Plan will be specific up to 5-7 years in the future. 
Planning beyond this period will be of a progressively 
more generic character. 

2.0 RESPONSIBILITIES 


The Strategic Plan for Information Handling Systems shall 
be jointly developed by the IHSA and organizations which 
supply, consume, or affect information services in some 
manner. 

The IHSA will be the focus for the planning activity and 
shall be responsible for: 

o Planning and coordinating the data collection, 

analysis, and the formulation of goals, objectives, 
and implementation strategies. 

o Integrating the parts into a cohesive Agency Plan 
and publishing the document. 

Organizations which supply, consume, or affect information 
services shall be responsible for supporting the IHSA in: 

o Data collection efforts (responding to directed 
questions or participating in working meetings). 

o Analysis of the environment - internal and external 
factors which may influence the plans for future 
information handling systems. 


* ::: internal use only -■ 
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o Analyzing interface problems associated with inter- 
operation of new and existing systems. 

o Developing top-level phaseover and conversion plans. 

3.0 DEVELOPMENT PROCESS 


Information Handling Systems Strategic Planning is phased 
into the following processes: 

o Environment data collection and analysis. 

o Architecture Definition. 

o Analysis of Performance. 

o Establishment of goals, objectives, and implemen- 
tation strategies. 

o Monitoring progress 
A brief discussion of each phase follows: 

Environment Data Collection and Analysis 

This phase is an examination of the current environ- 
ment in terms of its weaknesses, strengths, and future 
information handling requirements. A clear understanding 
of the current environment is necessary to project the 
future. Supplier, consumer, and other organizations with 
a vested interest in information services shall contribute 
to this phase by responding to specific questions and issues, 
and by participating in working meetings. The data base 
derived from this process will be key to setting goals, 
objectives, and implementation strategies for the future. 

Architecture Definition 

This phase is to develop a model of the Agency's infor- 
mation handling facilities, data bases, and processes. The 
model is to be targeted at 5-7 years in the future. The 
results of the environment analysis, technology fare costs, 
and affordability assessments will all influence the model. 
The model will describe (diagrammatically where possible) : 

o The structure of the Agency's information handling 
facilities and processes - their interoperability, 
interfaces, and functionality. 

o A unified information distribution network. 

o A universal terminal network. 


- 2 - 
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o Major Agency data bases - their composition, 

structure, residence, accessibility, use and inter- 
relationships . 

o Communication facilities. 

o Security and compartmentation . 

Establishment of Goals, Objectives, and Implementation 
Strategies 

This phase is the actual setting down of a plan to ac- 
complish certain goals and objectives. Implementation 
strategies are outlined giving consideration to the possible 
options. Priorities are established to guide programming 
and budgeting activities. 

Monitoring Progress 

The IHSA will monitor and coordinate planning, pro- 
gramming, and budgeting activities to determine whether 
the Strategic Plan is having its intended impact, and to 
collect data which may be pertinent to the next revision. 

4.0 METHODOLOGY 


The original plan will be developed in three phases. In 
the first, a rough draft plan will be developed. This plan 
will be disseminated fo all relevant Agency organization for 
comment and recommended changes. These responses will then 
be taken together with further architectural planning efforts 
and budgetary planning to produce a unified draft plan. The 
primary emphasis in the development of this second version 
of the plan will be on the reconciliation of budgetary con- 
siderations and system interoperation and architecture 
performance with time-phased implementation. Comments re- 
ceived from the circulation of this draft will then be in- 
corporated in the development of the final plan which will 
guide the Agency’s investment in Information Handling Systems 
over the next 5-7 years. 
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APPENDIX C 


Policy and Procedures for Management for Information Systems 


A. PURPOSE 

This document is to set forth Agency policy regarding 
management responsibilities for the acquisition of new or 
enhanced Information System capabilities. 

B. APPLICABILITY AND SCOPE 

The provisions of this document apply to automated or other 
clearly identifiable processes used for creation, movement, 
use, storage, retrieval, or dissemination of intelligence and 
management information. Included are ADP hardware and 
software systems, communications sytems, terminals, 
word-processing, printers and copiers, image processing and 
display systems. 

C. POLICY 

1. General 

Information System acquisitions shall be reviewed and 
approved at decision milestones by appropriate management 
levels. Systems of extraordinary cost, risk, or interest 
shall be reviewed by the EXCOM; the Information Handling 
Systems Architect (IHSA) and the Program Management 
Component shall support the EXCOM review process. 
Information Systems falling below the EXCOM review 
threshold, but nevertheless important in the context ojE 
Agency Information Systems Architecture and Planning, may 
be 'reviewed by the IHSA at decision milestones. 


2. Specific 

For purposes of management and coordination there are 
three classes of information systems, determined by 
investment cost thresholds. Class I and II systems shall 
comply with the procedures, standards, and documentation 
requirements for major programs. Class III programs 
shall comply with the procedures, standards and 
documentation requirements for minor programs. 
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a) Class I Informations Systems shall be reviewed and 
approved at decision milestones by the EXCOM. Any 
Information System, or any significant revision of an 
existing Information System, meeting any one of the 
following criteria shall be designated a Class I 
Information System: 

i) Has anticipated acquisition costs in excess of 
$8 million during the span from program 
initiation to the time the system becomes 
operational; or 

ii) Has estimated costs in excess of $2 mil] ion in 
any year; or 

iii) Is designated as being of special interest or 
considered to have Agency-wide or community 
importance. Nominations to the EXCOM can be 
made by any of the EXCOM principals or the IHSA. 

b) Class II Information Systems shall be reviewed and 
approved at decision milestones by the Deputy 
Director responsible for the system. Any Information 
System, or any significant revision of an existing 
Information System, meeting any of the following 
criteria shall be designated a Class II Information 
System: 

i) Has anticipated acquisition costs in excess of 
$1 million during the year from program 
initiation to the time the system becomes 
operational; or 

ii) Has estimated acquisition costs in excess of 
$250,000 in any year; or 

iii) Is designated as being of special interest. 

c) Class III Information Systems shall be reviewed and 
approved as the responsible Deputy Director may 
direct. In general, it is anticipated that he will 
delegate that authority to the next lower level of 
management. Any information system, or any 
significant revision of an information system which 
is in cost or importance less than Class II is a 
Class III system. 
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Milestone Decisions 

Three milestone decisions are defined for acquisition of 
Major Information Systems. 

o Milestone 0 Decision — Approval of Mission Need 
Statement approval of the budget and schedule, 
and authorization to proceed to the next program 
phase. The Mission Need Statement shall define 
the need for the system, and shall be 
accompanied by Preliminary System Requirements, 
acquisition strategy, schedule goals, and the 
total and annual investment of resources 
estimated. The next program phase for a simple 
package (no program development investment, 
e.g., a computer with standard support software) 
is the actual procurement, or, for a. complex 
system development , the next phase is the 
Concept Development Phase. 

o Milestone 1 Decision — Approval of the System 
Design Concept, System Requirements, and Program 
Development Plan; and authorization to proceed 
with the next program phase. For large complex 
systems, alternate concepts are to be explored 
and evaluated before settling on a chosen 
concept, the reasons for a particular selection 
are to be presented. Documentation at this 
stage shall include baseline System 
Requirements, System Design Concept, and a 
Program Development Plan. System requirements 
^_-rs>.will be accredited by the IHSA. Cost and 

/ schedule goals are reassessed. Equipment 
acquisition plans are presented for approval. 
Acquisition of production status, commercial 
hardware will normally be executed pursuant to 
this approval or direction. Approved programs 
then proceed to the Preliminary Design Phase. 

o Milestone 2 Decision — Approval of the 
Preliminary Design and Revised Program 
Development. All acquisition programs, however 
phased, will have a single Preliminary Design 
Review (PDR) covering the entire program. This 
review is coordinated with the program's 
internal PDR so that issues arising as a result 
of the PDR process can be evaluated. At this 
milestone review the program cost, 
functionality, and schedule objectives, as 
defined and determined at the PDR, are 
reassessed. Approved programs then proceed to 
full-scale development. 
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At each decision milestone, guidance and direction to 
the program are documented. 

At any point at which a major program deviation in cost 
or schedule goals of more than 10 percent is estimated, 
the IHSA will be notified. 

4. Procedures 

The IHSA will receive all documentation relevant to 
systems development for Class I and II systems. Included 
are such documents as: 

o Functional requirements 
o Program acquisition plan 

o Feasibility, analyses and tradeoff studies 
o System specification 
o Management plan 

o System functional specifications 
o Interface control specifications 
o System detailed design specifications 
o System test and validation plan 
o Periodic progress reports 

At least six months prior to Milestone 1 or 2 review of 
Class I and II systems the program sponsor will notify the 
IHSA. For Class I systems, the IHSA will coordinate and 
schedule an EXCOM review. 

The IHSA will appoint a member of his staff to coordinate 
with the program office concerning preparation for the 
Milestone review. The program office will brief the IHSA 
office with respect to the program status for Class I and II 
systems. Questions which the office of the IHSA has with the 
project will be addressed to the project management. The 
intent is to resolve all the questions that pertain to such 
matters as the project formulation, completeness of planning 
and design, interoperability, conformity with standards, and 
supportability prior to the Milestone review. 
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Prior to the review, the IHSA will prepare brief point 
papers covering any points of concern or disagreement 
.elative to the information system's development. 
Approximately one week prior to the EXCOM Milestone review 
of Class I systems, the IHSA will prebrief the EXCOM 
concerning unresolved issues and concerns. The project 
management will then brief the EXCOM on the system at the 
Milestone review. The IHSA will then prepare a decision 
coordinating paper documenting the EXCOM guidance and 
direction to the project. 

For Class II systems, if the IHSA feels that there are 
significant architectural concerns, he may join the 
Milestone review. 


5. IHSA Responsibilities 

The Information Handling Systems review process 
compliments the budgeting process. Information System 
decisions must fit into the affordability framework of 
the budget, and further, must fit into the Agency 
architecture and planning framework for Information 
Systems. In that context specific IHSA responsibilitie 
include: 

a) Formulating overall architecture tenets -for 
Information Systems 


b) Conducting formal reviews of proposed 
Information Systems to: 



o Accredit requirements 

o Determine compliance with architecture 
tenets 

o Validate Functional Requirements 
o Validate System Concept 
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o Ensure that relevant interfaces are 
considered 

o Validate information security of proposed 
design 

c) Advising on relative priorities of Information 
Systems 

d) Focusing the issues for EXCOM reviews 


e) Making an annual report to the EXCOM on the 

status of IHSs in the Agency and advising EXCOM 
on Information Handling Systems decisions 


f) Designated individual for the Agency, assuring 
compliance with government-wide standards and 
procedures. Included is assuring Agency 
compliance with Federal Information Processing 
Standards, and granting waivers to these in 
accordance with delegated authorities and 
specified procedures. 
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APPENDIX D 


DRAFT HR 


OFFICE OF INFORMATION HANDLING SYSTEMS ARCHITECT 


(1) MISSION 

(a) Leads Agency level planning for Information Handling 
Systems soliciting, coordinating, and integrating 
inputs from organizations which supply, consume, 

or affect information services. 

(b) Reviews major information Handling Systems during 
requirements definition and conceptual design stages 
to ensure that overall Agency interests are properly 
considered . 

(2) FUNCTIONS: 

(a) Develops and publishes strategic goals and objectives 
for purpose of program guidance. 

(b) Monitors progress toward goals and objectives the 
reports state of Information Handling to EXCOM 
(incorporates ADP review) . 

(c) Provides approval for all agency information handling 
systems architecture. 

(d) Consolidates requirements for IH to maximiz^ commonality 
and minimize unique development. 

(e) Conducts design reviews during conceptual design phase. 

(f) Maintains technology forecasts and reports trends to 
developers, users and management. 

(g) Acts as Agency focal point to Community on matters 
of IH. 

(h) Commissions system designs to fulfill architecture. 

(i) Initiates studies and analyses for the purpose of 
identifying ways to improve the effectiveness and 
efficiency of IH. 

(j) Maintains a current data base on the status of Agency 
information systems and their interrelationships. 

(k) In coordination with other Agency components , 
formulates and promulgates standards to be applied 
to Information Handling Systems. 
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(l) Assures compliance with Agency Standards; 
grants waivers in accordance with delegated 
authority. 

(m) Coordinates Information Handling Systems training 
programs for developers and users. 
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